Authentication and verification services for third party vendors using mobile devices

ABSTRACT

A method to provide authentication services to third party vendors by a service provider hosting an authentication, authorization and accounting (AAA) server or a similar device that can authenticate users for some other service. This method enables easy and substantially error-free end-user authentication, which forms the basis for enabling electronic transactions (e.g., web-based) that are less vulnerable to fraud.

FIELD OF THE INVENTION

The present invention relates generally to the fields of communicationprotocols and internetworking and, in particular, relates to security,authentication, e-commerce, wireless networks, buyers and sellers, andmobile computing.

BACKGROUND OF THE INVENTION

Vendors would prefer to improve the shopping experience for consumers bymaking purchase transactions more secure, without forcing consumers toswipe their credit cards and provide identification to verify theiridentities. Also, fraud and identity theft have become pervasiveproblems.

Traditional world wide web electronic transactions involve the keying ofan end-user's name and credit/debit card number with some associatedauxiliary security verification information (ASVI) (e.g., the cardverification value (CVV) number, user address, billing zip code, year ofbirth of the user, etc.) into a vendor's webpage for billing. The vendorpasses this information to the transaction handler (or payment gateway),who verifies the authenticity of the provided information and conveysthe result to the vendor. The vendor then completes the transaction bybilling the user.

While the ASVI information is supposed to be known only to the end-user,practical constraints force the user to have a fixed set of thisinformation. This information could be knowingly or inadvertently storedat many points in the network by some vendors with whom the user hastransacted in the past. In addition, ASVI information is stored by thetransaction handler (or payment gateway). This data is, therefore, morevulnerable to theft and compromise. The identity of the user can beimpersonated by anyone in possession of the ASVI information in additionto the credit/debit card information.

SUMMARY

Exemplary embodiments of the present invention provide authenticationand verification services for third party vendors using mobile devices,eliminating the need for the vendor to solely rely on the ASVIinformation in order to authenticate the user.

One embodiment is a method for performing authentication. A name and amobile device identifier are received from a vendor. It is verified thatthe name received from the vendor is the same as the name of the ownerof the mobile device that was identified by the mobile deviceidentifier. A new data string is generated and the same data string issent to both the vendor and the mobile device. The user's identity isverified by determining that the data string received by the vendor isthe same as the data string received by the mobile device. Anotherembodiment is a computer readable medium storing instructions forperforming this method.

In another embodiment of a method for performing authentication, a nameand a mobile device identifier are received from a vendor. It isverified that the name received from the vendor is the same as the nameof the owner of the mobile device that was identified by the mobiledevice identifier. A data string is sent to the mobile device, which ispassed to the vendor. The data string can be randomly generated. Then,the same data string is received from the vendor. The user's identity isverified by determining that the two data strings are the same. Anotherembodiment is a computer readable medium storing instructions forperforming this method.

In yet another method for performing authentication, a first data stringis sent to a mobile device. A name, a mobile device identifier, and asecond data string are received from a vendor. It is verified that thename received from the vendor is the same as the name of the owner ofthe mobile device that was identified by the mobile device identifier.The user's identity is verified by determining that the first datastring is the same as the second data string that was sent to the mobiledevice. Another embodiment is a computer readable medium storinginstructions for performing this method.

In still another method for performing authentication, a name, a mobiledevice identifier, and a set of transaction information is received froma vendor. It is verified that the name received from the vendor is thesame as the name of the owner of the mobile device that was identifiedby the mobile device identifier. The transaction information is sent tothe mobile device, which can be optionally verified by the user. Anotherembodiment is a computer readable medium storing instructions forperforming this method.

BRIEF DESCRIPTION OF THE DRAWINGS

The teachings of the present invention can be readily understood byconsidering the following detailed description in conjunction with theaccompanying drawings, in which:

FIG. 1 is a block diagram that shows a traditional electronictransaction;

FIG. 2 is a block diagram that shows an exemplary embodiment of a methodfor authentication and verification services for third party vendorsusing mobile devices;

FIG. 3 is a block diagram that shows another exemplary embodiment of amethod for authentication and verification services for third partyvendors using mobile devices;

FIG. 4 is a block diagram that shows yet another exemplary embodiment ofa method for authentication and verification services for third partyvendors using mobile devices;

FIG. 5 is a block diagram that shows still another exemplary embodimentof a method for authentication and verification services for third partyvendors using mobile devices;

FIG. 6 is a block diagram that shows an exemplary embodiment of a methodfor automatic billing services with user verification for third partyvendors using mobile devices;

FIG. 7 is a block diagram that shows yet another exemplary embodiment ofa method for authentication and verification services; and

FIG. 8 is a high level block diagram showing a computer.

To facilitate understanding, identical reference numerals have beenused, where possible, to designate identical elements that are common tothe figures.

DETAILED DESCRIPTION OF THE INVENTION

The present invention will be primarily described within the generalcontext of embodiments of methods and system for authentication andverification services for third party vendors using mobile devices.However, those skilled in the art and informed by the teachings hereinwill realize that the invention is generally applicable to any kind ofdevice capable of receiving information (e.g., personal digitalassistants, laptops, cell phones, mobile or portable device, or othercomputing devices), authentication service, authorization service,accounting service, verification service, automatic or manual billingservice, security application, transaction types, selling, buying,shopping, sellers, vendors, merchants, shops, websites, buyers,consumers, banks, credit cards, other commercial and financial entities,and any other devices, services, and types of networks.

There must be a better way for vendors to improve the shoppingexperience for consumers by making transactions faster and easier,without forcing consumers to swipe their cards and provideidentification to verify their identities. Also, fraud and identitytheft have become pervasive problems. At the same time, most people nowalways carry mobile phones or other portable devices. Increasingly,mobile phones and other portable devices have more and morefunctionality. In the case of identity theft, the thief has access tothe user's information (e.g., credit card number) but the user is notaware that the thief has access. However, nobody can use a mobile deviceunless they have actual physical possession of the mobile device. Amobile phone is one example of such a mobile device. Like a driver'slicense, a mobile phone is something a person always has in his or herpossession and, thus, is available for identification purposes. If itwere just a number, like a social security number, anyone could use itjust by knowing the number, without having possession of the physicalsocial security number card. The mobile phone is in close physicalproximity with the user. Unlike a passive driver's license, the mobilephone and other mobile devices not only provide identification, but alsosend and receive information, such as text messages.

One exemplary embodiment is a method for providing authenticationservices to third party vendors that eliminates the need for a vendor tosolely rely on ASVI information in order to authenticate the user.Authentication services are provided by a service provider hosting anauthentication, authorization and accounting (AAA) server, a billingrecords server, or a similar device to authenticate users for some otherservice. This enables easy and substantially error-free end-userauthentication that forms the basis for enabling electronic transactions(e.g., web-based) and other services that are less vulnerable to fraud.

Consider a transaction in a supermarket where a counter-clerk visuallyauthenticates a user using his photo identity card (e.g., driver'slicense) as an authentication mechanism in addition to the ASVIinformation. Another authentication mechanism that is available inexemplary embodiments for a user that always carries a mobile device.The mobile device is served by a service provider. The service providermay provide wireless service or some connectivity or other service tothe user. Alternatively, the service provider may be a third partyproviding authentication and verification service for a vendor. Forexample, a corporate entity may provide email service to the user. Theservice provider has an authentication server, typically as part of anAAA server that authenticates the mobile device carried by the user.Specifically, the user account is associated with the user's name (andoptionally the user's address) and information and an identifierspecific to the mobile device, (e.g., subscriber identity module (SIM)or electronic serial number (ESN)). Whenever the mobile device isconnected to the network of the service provider, this authenticationcan be performed and periodically verified. Of course, the user needs toimmediately notify the service provider if the mobile device is stolenor lost.

FIG. 1 shows a traditional electronic transaction 100 between a user (U)102 and a vendor (V) 104 (e.g., a grocery store, an e-commerce store, abilling agent, or any person or organization that accepts an alternativepayment in lieu of cash) via a transaction handler (CC) 106, (e.g., abank, a credit card company, a payment gateway, or any entity handlingand verifying financial transactions, or a combination of these). Instep 1, the user 102 sends his name and optionally his address, both ofwhich are denoted by “NAME” in FIG. 1, and account number denoted by“Num” (e.g., the credit/debit card number, or other account number)along with the ASVI information 108 (e.g., the card verification value(CVV) number, billing address, billing zip code, year of birth of theuser, etc.) to the vendor 104, who passes this information 110 to thetransaction handler 106 in step 2. This information 110 is verified bythe transaction handler, who sends an okay or fail message (step 3) 112to the vendor 104 regarding the authenticity of the billing informationprovided and, in addition, the authenticity of the user credentials,(not the authenticity of the user). Upon receiving the message 112, thevendor 104 successfully processes the transaction (step 4) 114 andsubsequently provides the service(s) to the user 102.

One problem with the traditional electronic transaction 100 is that theuser 102 could be faking the credentials (i.e., account number and ASVIinformation) and both the vendor 104 and the transaction handler 106 arepowerless to detect it. Additional authentication involves storage ofmore personal information about the user 102, such as biometric data.However, most additional authentication is either prohibitivelyexpensive, or not portable, or not easy to use, or significantly erodesthe privacy of the user 102. Even this additional authentication issubject to abuse, because this information is usually stored at thetransaction handler 106 and, hence, can be stolen. A public keyinfrastructure (PKI) can be used for end-user authentication, where theuser 102 encodes his information with his private key. However, PKI isnot used pervasively by any party in traditional electronictransactions, due to its inconvenience and privacy considerations.

In the traditional electronic transaction 100, the authenticationservice is provided by the transaction handler 106. Again, thetransaction handler 106 authenticates only user credentials, not theuser. There is a need for an authentication service that is separatefrom the transaction handler, which provides more control for thevendor, helping the vendor 104 verify the identity of user 102. ASVIinformation is often stored in a database by the transaction handler.So, a thief could steal the ASVI information in the database and pretendto be a user in a transaction with a vendor. When the fraud comes tolight, the vendor is stuck with all the fraudulent charges. By contrast,exemplary embodiments add an additional authentication mechanism that issubstantially simple, fool-proof, and easy to use. One such exemplaryembodiment is outlined in FIG. 2.

FIG. 2 shows an exemplary embodiment 200 of a method for authenticationand verification services for third party vendors using mobile devices.This exemplary embodiment introduces a third party, the service provider(SP) 202 and a third party authentication service that can be used by avendor (V) 104. In this exemplary embodiment, the user (U) 102 sends hisname, (optional address) number, and ASVI information 206 as usual, butalso sends the identity of the mobile device (M) (e.g., M=cell phonenumber, SIM card number, or ESN number) to the vendor (V) 104 (step 1206). The vendor identifies the service provider 202, which canauthenticate M and sends the service provider the information (step 2208), i.e., name (optional address) and M. The vendor sends thisinformation with equipment, such as a cash register machine, a personalcomputer (PC), a credit card verification machine, or a standalonedevice. This equipment is provided to the vendor by the serviceprovider, in one embodiment. In another embodiment, the information istransmitted electronically by the vendor to the service provider. Theservice provider 202 checks if the identity of the mobile device, M, isauthenticated against a user with the same name (and optionally address)as user 102. In other words, the service provider checks that the personwith that name (and optionally address) is the same person who owns themobile device identified by M. If so, then the service provider sendsthe mobile device 204 and the vendor a data string of information, rand,(step 3 210). In another embodiment, the data string can be generated atrandom by the service provider.

The data string is not stored and is generated at this point in eachtransaction. The data string does not necessarily follow any pattern,but this exemplary embodiment does not preclude that. However, a datastring affords more security. The data string can be any sequence ofcharacters, numbers, images, sounds, or any randomly chosen pieceinformation capable of being sent from the service provider and receivedby both the mobile device 204 and the vendor 104.

The user 102 receives the data string on his mobile device 204 and,then, sends the data string to the vendor 104 (step 4 212). The vendor104 verifies this with the string received from the service provider(previously in step 3 210) and if it matches, then the vendor 104 isassured that the user 102 is indeed in possession of his registeredmobile device 204 and, therefore, who he claims to be according to theservice provider 202. Now, the vendor 104. proceeds with the rest of thetransaction with the transaction handler 106. If that part of thetransaction succeeds as well, the vendor 104 has authenticated the user102 using two independent methods: one using a physical validity test(using the mobile device 204) and the other using a traditionalfinancial validity test (using the transaction handler 106).

Any thief wishing to fake the identity of the user 102 will have tocompromise not only the account number, name, and ASVI, but alsophysically compromise the mobile device 204. The knowledge of the mobileidentifier, M, or the data string cannot help the thief, because thedata string changes with every transaction, i.e., it is unique for eachtransaction. Thus, vendors 104 can rely on the physical proximity of themobile device 204 to their owners (user 102) in order to verify theiridentity by an additional, independent means.

For example, a user walks into a Starbucks and uses a credit card topurchase a coffee drink. The user gives his name and cell phone numberto the cashier and quickly receives a text message from his cell phoneprovider with the code “9945”. The cashier also receives “9945” on thecash register machine. The user tells the cashier the code so that thecashier knows that the user is the same person associated with the cellphone number. The cashier sends the user's name, credit card number, andother information to the credit card company and completes the sale inthe usual way.

Now, suppose the user drops his credit card on the way out and a thiefpicks it up and goes to the Starbucks counter and attempts to use theuser's credit card number for a purchase. The cashier asks the thief forhis name and cell phone number. If the thief gives the user's cell phonenumber, then the thief will not receive the message, because the user isin possession of the cell phone. If the thief gives his own name and hisown cell phone number, his name and cell phone number are not going tomatch the name on the credit card during authentication. If the usergives the stolen name, stolen credit card information and his own cellphone number, then the name and phone number will fail verification bythe service provider. Thus, a thief cannot fake either the user's nameand the user's cell phone number or both and expect to get away with it.A fraudulent transaction will fail either at the service provider 202 orthe transaction handler 106 so, the vendor 104 has two opportunities todetect the fraud.

Electronic commerce transactions can also be handled in a similarmanner. When a user's purchase information is stolen and misused bysomeone else, the coupling of the mobile device identity with thefinancial information prevents misuse and financial fraud.

This exemplary embodiment provides a different authentication mechanism200 that allows a service provider 202 to give a data string 210 to amobile device 204 to control the mobile device 204 in response to arequest from a vendor 208, from whom the user 102 requests some servicein exchange for a payment. Communication of the data string, rand, tothe mobile device 204 can be performed via a data channel or a controlchannel. In general, messaging involving the mobile device 204 may beover a data channel or a control channel. The data channel may be usedfor a text message, voice prompt, multimedia message and the like. Inone embodiment, messages are presented on the mobile device 204 with amenu for authentication and verification services. Some examples ofmessages include short message service (SMS), text, instant messaging,video messaging, multi-media messaging, voice-activated speech, humanconfirmation and the like. Messages over a control channel have separatesignaling. The control channel may be a dedicated control channel.

FIG. 3 shows another exemplary embodiment of a method for authenticationand verification services for third party vendors using mobile devices.This exemplary embodiment performs a similar set of transactions, buthere the service provider 202 sends the data string only to the mobiledevice 204 and this information is given to the vendor 104 by the user102, who receives it on his mobile device 204. The first and secondsteps 302, 304 are the same as those 206, 208 in FIG. 2. In the thirdstep 308, the service provider 202 sends the data string to the user 102directly. Then, the user 102 sends the data string to the vendor 104(step 4 308), who forwards it to the service provider 202 (step 5 310)and the service provider verifies whether the data string is correct andnotifies the vendor (step 6 312). Here, the responsibility for verifyingthe data string is correct lies with the service provider 202, ratherthan the vendor 104, as in FIG. 2. The remaining steps 314, 316 aresimilar to those 214, 216 in FIG. 2.

FIG. 4 shows yet another exemplary embodiment of a method forauthentication and verification services for third party vendors usingmobile devices. In this exemplary embodiment, in step 0 402, the serviceprovider 202 sends a different data string periodically to the mobiledevice 204 of every registered user 102 in its network. This informationis sent by the user 102 (step 1 404) as part of the transaction to thevendor 104 in addition to the name, mobile number (M), and ASVIinformation. The vendor 104 sends the name, mobile number, and ASVIinformation to the service provider 202 (step 2 406) for verificationand, upon successful verification (step 3 408), proceeds with the restof the transaction (steps 4 and 5 410, 412). In an alternate embodiment,the user 102 explicitly requests a data string from the service provider202 before initiating a transaction, eliminating the need for theservice provider 202 to periodically generate data strings for all thedevices in its network. This exemplary embodiment may be faster (i.e.,decreased transaction time) and more efficient than that shown in FIG.3, because it has fewer steps (six vs. nine) and less overhead.

Communication between the vendor 104 and the service provider 202 can beeither direct or via an authentication broker (not shown), who handlestransactions between numerous vendors and various service providers. Thebroker can provide services to identify the mapping between a mobiledevice number (M) and its authentication service provider 202 and routethe requests and responses appropriately to the correct vendor 104 andservice provider 202.

The responsibility for authenticating the user lies primarily with thevendor 104, in the exemplary embodiments shown in FIGS. 1-4, whichreflects practical constraints in the current world of electroniccommerce. Vendors are not compensated for fraudulent charges made bycompromised credit cards.

One advantage of exemplary embodiments lies in both the ubiquity ofmobile devices that are associated with a centrally controlled networkand in the fact that mobile devices 204 are carried by nearly everyone,thereby removing the need to carry a separate authentication device,such as a smart card. By separating the mobile device 204 interactionfrom the financial aspect of the transaction problem, the potential forabuse of stolen mobiles is reduced, because a thief would have to stealthe device as well as the financial instrument information (e.g.,credit/debit/smart card) and the ASVI for that instrument and user 102.While the latter information can be centrally stored, the mobile devicestate cannot be stored in the same place, stolen or replicatedsuccessfully by a thief who wants to masquerade as the user 102.

FIG. 5 shows still another exemplary embodiment of a method forauthentication and verification services for third party vendors usingmobile devices. This exemplary embodiment illustrates providingverification services and is useful for applications where details aboutthe transaction are available. For example, users 102 can use thisservice to verify details about the transaction, (e.g., what is beingcharged to his or her credit card). As part of verifying the identity ofthe user 102 during a transaction using his or her mobile number, thevendor 104 sends some transaction information, TrDetail, to the serviceprovider 202 (step 2 502).

The TrDetail may include information about the vendor 104, the name ofthe user making the transaction, the items or services involved in thetransaction, the cost of the transaction, or other information relatedto the transaction. In one embodiment, the message sent in step 3 504 tothe mobile device 204 may server as a receipt for the user 102.

After authenticating the user 102 via his or her mobile deviceregistration, the service provider 202 sends the TrDetail information tothe mobile device 204 (step 3 504). The user 102 can cross-check thisinformation and send an okay or fail message back to the serviceprovider 202 about the transaction (step 4 506). All messages areidentified by an ID number that is unique, at least for eachtransaction. The ID number is included in each message, enabling theservice provider 202 and the vendor 104 to track the progress of theauthentication and verification. If the user 102 verifies thetransaction (step 4 506), then the service provider 202 passes thisinformation to the vendor 104 (step 5 508) and the transaction proceedsas before (steps 6 and 7 510, 512). There is no data string involved inthis exemplary embodiment.

In one exemplary embodiment, a user→ mobile device→ service provider→vendor pathway is used to pass the ASVI information to the vendor 104,as opposed to sending the information directly to the vendor 104. Thisadvantageously provides two near-independent pathways (independence iseither in space or time or both) for transmittal of secure financialinformation.

Consider a user 102 who has multiple copies of a credit card, one forhimself, one for his spouse, and one for each child. This exemplaryembodiment enables the user 102 to have some control over what is beingcharged to the credit card by his spouse and children. The user 102 canmaintain possession of the mobile device 204 and, therefore, eitherapprove or disapprove each purchase in step 4 506, after receiving thetransaction detail information in step 3 504.

In another scenario, suppose the user 102 and his spouse share a creditcard and each has a different mobile device 204. The service providersends the transaction detail message in step 3 504 to the mobile device204 owned by the purchaser, or to each mobile device 204 for approval instep 4 506, as desired. For example, they might set up the service oraccount to allow each spouse a veto power over purchases, one spouse mayhave approval rights for all purchases, or each may approve their ownpurchases.

FIG. 6 shows an exemplary embodiment of a method for automatic billingservices with user verification for third party vendors using mobiledevices. A verification service can be used to ensure that usersregistering for periodic or automatic billing services are notified andbilled only upon their verification (at least initially or until a duedate), among other applications. In this exemplary embodiment, thevendor 104 uses pre-stored information, which can also include ASVI orcan be obtained from the user as part of the verification process. Thevendor 104 uses pre-stored information (step 1 600) to initiate aperiodic or automatic transaction. The user 102 is notified, afterhaving the identity authenticated by the service provider 202 (with themobile device 204) of the TrDetail. The rest of the method is similar tothe method described with reference to FIG. 5.

For example, a vendor sends a bill, (e.g., electric or water bill) astransaction detail information in step 3 604 for approval beforedebiting your bank account. Receiving a message on the mobile device 204and pressing OK before a due date is more convenient for the user 102than logging on to a website or having to write a check.

For example, a vendor sends transaction detail indicating that the user102 has been billed in step 3 604 for an automatic billing service(e.g., phone bill). This automatic payment is not dependent on approval.The first time the automatic billing service is set up, approval may berequired. Thus, step 4 606 is optional.

FIG. 7 shows yet another exemplary embodiment of a method forauthentication and verification services. In this exemplary embodiment,the authentication and verification services are provided by thetransaction handler 106, instead of the service provider 202, as inother embodiments. In this embodiment, the service provider 202 can belocated at either the payment gateway that routes the information to theappropriate financial network or the company that verifies thecredit/debit card information, or the bank that processes the finalpayment, all of which are represented in FIG. 7 by transaction handler106. The methods shown in FIGS. 2, 3, 4, 5, and 6 can be adapted to thismodel, where the service provider functions are provided by one of thecomponent entities of the transaction handler 106. The number oftransaction steps in this embodiment is less than if the serviceprovider were an independent entity. The mobile identifier, M, isregistered by the user 102 at a time prior to the transaction, such aswhen the user obtains or activates the credit/debit card, “Num” andstored (in a storage device, such as a database, which is not shown) bythe transaction handler 106 in association with the user's informationfor later verification.

At 702 (step 1), the user 102 sends his name, (optional address), M,Num, and ASVI information to the vendor 104, who passes it onto thetransaction handler 106 at 704 (step 2). At 706 (step 3), the serviceprovider 202 sends the data string, rand, to both the vendor 104 and theuser 102. The data string may be randomly generated. At 708 (step 4),the user provides the data string to the vendor 104. At 710 (step 5),the transaction handler 106 provides an okay or fail message based onwhether the user information was the same as the registrationinformation stored prior to the transaction. At 712 (step 6), the vendor104 notifies the user 102 whether the transaction succeed.

In one exemplary embodiment, the mobile device identifier, M, isreceived by an inquirer, such as the vendor 104, service provider 202,or transaction handler 106. The mobile device identifier is associatedwith one or more identities and other data (e.g., name, address, accountnumber). The identity is provided for use in authenticating atransaction.

FIG. 8 is a high level block diagram showing a computer. The computer800 may be employed to implement embodiments of the present invention.The computer 800 comprises a processor 830 as well as memory 840 forstoring various programs 844 and data 846. The memory 840 may also storean operating system 842 supporting the programs 844.

The processor 830 cooperates with conventional support circuitry such aspower supplies, clock circuits, cache memory and the like as well ascircuits that assist in executing the software routines stored in thememory 840. As such, it is contemplated that some of the steps discussedherein as software methods may be implemented within hardware, forexample, as circuitry that cooperates with the processor 830 to performvarious method steps. The computer 800 also contains input/output (I/O)circuitry that forms an interface between the various functionalelements communicating with the computer 800.

Although the computer 800 is depicted as a general purpose computer thatis programmed to perform various functions in accordance with thepresent invention, the invention can be implemented in hardware as, forexample, an application specific integrated circuit (ASIC) or fieldprogrammable gate array (FPGA). As such, the process steps describedherein are intended to be broadly interpreted as being equivalentlyperformed by software, hardware, or a combination thereof.

The present invention may be implemented as a computer program productwherein computer instructions, when processed by a computer, adapt theoperation of the computer such that the methods and/or techniques of thepresent invention are invoked or otherwise provided. Instructions forinvoking the inventive methods may be stored in fixed or removablemedia, transmitted via a data stream in a broadcast media or othersignal bearing medium, and/or stored within a working memory within acomputing device operating according to the instructions.

While the foregoing is directed to various embodiments of the presentinvention, other and further embodiments of the invention may be devisedwithout departing from the basic scope thereof. As such, the appropriatescope of the invention is to be determined according to the claims,which follow.

1. A method, comprising: receiving a mobile device identifier from aninquirer; associating the mobile device identifier with at least oneidentity and other identifying data; and providing the identity for usein authenticating a transaction.
 2. The method of claim 1, wherein theinquirer is one of a vendor, a service provider, or a transactionhandler.
 3. The method of claim 1, further comprising: verifying that anowner of a mobile device identified by the mobile device identifier isassociated with the other identifying data.
 4. The method of claim 1,further comprising: receiving a name and the mobile device identifier;and verifying that an owner of a mobile device identified by the mobiledevice identifier is associated with the received name.
 5. The method ofclaim 4, further comprising: sending a data string to both the inquirerand the mobile device identified by the mobile device identifier.
 6. Amethod for performing authentication, comprising: receiving a name and amobile device identifier from a vendor; verifying that an owner of amobile device identified by the mobile device identifier is associatedwith the received name; and sending a data string to both the vendor andthe mobile device identified by the mobile device identifier.
 7. Themethod of claim 6, further comprising: verifying a user's identity bycomparing the data string received by the vendor with the data stringreceived by the mobile device.
 8. The method of claim 6, furthercomprising: randomly generating the data string.
 9. The method of claim6, wherein an address is received along with the name and the mobiledevice identifier; and further wherein verification includes verifyingthat the owner of the mobile device is associated with both the receivedname and the received address.
 10. A method for performingauthentication, comprising: receiving a name and a mobile deviceidentifier from a vendor; verifying that an owner of a mobile deviceidentified by the mobile device identifier has the received name; andsending a first data string to the mobile device identified by themobile device identifier; receiving a second data string from thevendor; and verifying a user's identity by determining that the seconddata string received from the vendor is the same as the first datastring sent to the mobile device.
 11. A computer readable medium storinginstructions for performing the method of claim
 10. 12. The method ofclaim 11, further comprising: randomly generating the first and seconddata string.
 13. The method of claim 10, wherein an address is receivedalong with the name and the mobile device identifier; and furtherwherein verification includes verifying that the owner of the mobiledevice is associated with both the received name and the receivedaddress.
 14. A method for performing authentication, comprising: sendinga first data string to a mobile device; receiving a name, a mobiledevice identifier, and a second data string from a vendor; verifyingthat an owner of the mobile device identified by the mobile deviceidentifier has the received name; and verifying the user's identity bydetermining that the first data string is the same as the second datastring.
 15. The method of claim 14, wherein the first data string is oneof a plurality of data strings sent periodically to the mobile device.16. The method of claim 14, wherein the first data string is sent inresponse to a request from a user.
 17. The method of claim 14, furthercomprising: randomly generating the data string.
 18. The method of claim14, wherein an address is received along with the name and the mobiledevice identifier; and further wherein verification includes verifyingthat the owner of the mobile device is associated with both the receivedname and the received address.
 19. A computer readable medium storinginstructions for performing the method of claim
 14. 20. A method forperforming authentication, comprising: receiving a name, a mobile deviceidentifier, and a set of transaction information from a vendor;verifying that an owner of a mobile device identified by the mobiledevice identifier has the received name; and sending the set oftransaction information to the mobile device.
 21. The method of claim20, further comprising: receiving approval from the mobile device inresponse to the set of transaction information.
 22. The method of claim20, further comprising: providing a status to the vendor.
 23. The methodof claim 20, wherein the vendor stores the name and the mobile deviceidentifier.
 24. The method of claim 20, wherein the vendor receives thename and the mobile device identifier from a user.
 25. A method forperforming authentication, comprising: storing a user name and anassociated user mobile device identifier prior to any transaction;receiving a name, a mobile device identifier, and a set of transactioninformation from a vendor; and verifying that the stored user name andthe stored, associated mobile device identifier are the same as thereceived name and the received mobile device identifier; wherein aservice provider sends a data string to both a vendor and the mobiledevice identified by the mobile device identifier.